In UMTS, MBMS has been introduced in release 6. In services in which a plurality of users require the same information, it is an object of MBMS to allow effective use of radio resources and network resources by transmitting the same information using common channels, rather than transmitting information using a dedicated for every individual user.
First, an outline of MBMS in UMTS will be explained. Non-Patent Document 1 discloses an outline of these behaviors, and Non-Patent Document 2 discloses behaviors in RRC (Radio Resource Control) in detail.
FIG. 1 shows the channels used when MBMS is provided point-to-multipoint in UMTS. This figure also shows the relationships between logical channels, a transport channel and a physical channel. For the logical channels, three of MBMS point-to-multipoint traffic channel (MTCH), MBMS point- to-multipoint control channel (MCCH), and MBMS point-to-multipoint scheduling channel (MSCH) are defined new for MBMS.
Here, the MTCH refers to the channel for transmitting MBMS data and is a data channel. Further, the MCCH refers to the channel including control information for providing MBMS and is a control channel. Furthermore, the MSCH refers to the channel for transmitting MTCH scheduling information and is a control channel.
Next, for the transport channel, a forward access channel (FACH) is used to transmit the three logical channels. The FACH has been present in UTMS and is not a channel defined new for MBMS.
Finally, for the physical channel, a secondary common control physical channel (S-CCPCH) is used to transmit the FACH. The S-CCPCH has also been present in UTMS and is not a channel defined new for MBMS.
Now, layer 2 and layer 3 will be mainly explained below. First, the above-described MCCH will be explained in detail. The MCCH is broadly classified into two categories, that is, “critical” and “non-critical.” “Critical” is furthermore divided into three systems, namely notification messages, RB (Radio Bearer) information messages, and general MBMS-related information messages. By contrast with this, “non-critical” refers only to counting messages.
To be more specific, notification messages include “MBMS modified services information” (i.e. message for designating modified service information, including behaviors for terminals after the message) and “MBMS unmodified services information” (i.e. message for designating unmodified service information, including behaviors for terminals after the message).
Further, RB information messages include “MBMS common P-T-M RB information” (including common setups between services in RB information), “MBMS current cell P-T-M RB information” (including setups in cells of terminals in RB information) and “MBMS neighboring cell P-T-M RB information” (including setups in neighboring cells in RB information).
Furthermore, general MBMS-related information messages include “MBMS general information” (including preferred frequency, MBMS timer, counter information, MSCH configuration information and so on).
On the other hand, “non-critical” includes “MBMS access information” (including information related to counting).
By receiving the MCCH messages defined as above and setting up in the terminals, the terminals can receive the MTCHs actually transmitting data and the MSCHs transmitting the MTCH scheduling information.
Next, notification and counting will be explained. In MBMS, services are provided not at all times but are provided either regularly or irregularly. As a specific example, in services such as mobile TV, the same programs (the content changes every time or every several times) are delivered regularly and stock price information is transmitted regularly.
In addition, examples of irregularly provided services include newsflash, which is limited to specific information and which is delivered when news is updated. To support these services, it is necessary to notify terminals that services in which users are interested start to be provided in a network. This behavior is “notification.”
“Notification” has broadly two kinds of behaviors. The first behavior refers to checking whether or not services which a terminal requests are provided by checking the above-described notification messages defined by the MCCH by the terminal. The second behavior refers to, by an MBMS indicator channel (MICH), notifying that it is necessary to check the above-described notification messages defined in the MCCH.
In this way, in the “notification,” there are a method of checking a notification message by the terminal in one step and a method of checking a notification message by the terminal in two steps.
As described above, whether or not it is necessary to provide a specific service as MBMS in a cell, and, if necessary, how to provide the specific service, are determined by performing counting. Whether or not it is necessary to provide a specific service in a cell is determined by checking whether there are terminals requesting the specific service.
To be more specific, first, the network transmits to terminals a parameter referred to as “probability factor,” as information for performing counting for the service to be provided from now on. To prevent channel congestion caused when all terminals requesting the specific service respond, this parameter makes only part of the terminals requesting the specific service respond.
Here, amongst the terminals requesting the specific service, the network identifies a terminal that has responded, so that the network learns that it is necessary to provide the specific service to its cell. If there is no response from terminals, the value of the probability factor is changed to allow more terminals to respond.
The network determines next how to provide the service. For example, in multicast the same information is transmitted to a plurality of terminals, so that it is necessary to transmit information with high power taking into account terminals present at the cell edge. However, if few terminals request a specific service, there are cases where it is better to transmit the same information to each terminal. The network is also required to make determinations about such cases. As a specific example, if there are equal to or more than four terminals, MBMS is provided by multicast, and if there are less than four terminals, MBMS is transmitted individually. In this example, the network checks using counting there are equal to or more than four terminals.
Next, the behaviors until a terminal receives the MCCH will be explained using FIG. 2. As described above, the MCCH is transmitted in a FACH (S-CCPCH corresponding to a physical channel). There are three parameters to show MCCH transmission behaviors, including the modification period, repetition period and access information period. During the modification period, MCCH critical messages cannot be changed and the contents of critical messages, which can be transmitted several times during this period, are all the same. However, non-critical messages can be changed during this period.
Further, the repetition period refers to the intervals in which MCCH critical messages are repeated and the modification period is an integral multiple of the repetition period. Further, the access information period refers to intervals in which MCCH non-critical messages are repeated.
These parameters allow to learn what timing a terminal acquires the MCCH. Other than these parameters, a terminal needs to acquire information about the FACH (S-CCPCH corresponding to a physical channel), whereby the MCCH is transmitted. These channel information and information related to MCCH transmission interval are transmitted in an SIB 5 as broadcast information. That is, by receiving the SIB 5, a terminal is allowed to receive the MCCH. To receive the SIB 5, a terminal needs to SIB scheduling information and acquires scheduling information included in a MIB. This is a general broadcast information acquiring behavior.
As such, many behaviors are defined new in MBMS of UMTS release 6, and therefore MBMS of UMTS release 6 is a very complicated system.    Non-patent Document 1: 3GPP TS25.346 V6.8.0 “Introduction of the Multimedia Broadcast Multicast Service in the Radio Access Network”    Non-patent Document 2: 3GPP TS25.331 V7.1.0 “Radio Resource Control”